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(57) ABSTRACT 

A group packet encapsulation and (optionally) compression 
system and method, including an encapsulation protocol 
increases packet transmission performance between two 
gateways or host computers by reducing data-link layer 
framing overhead, reducing packet routing overhead in 
gateways, compressing packet headers in the encapsulation 
packet, and increasing loss-less data compression ratio 
beyond that otherwise achievable in typical systems. Packets 
queued at a node configured in accordance with the present 
invention are classified, grouped, and encapsulated into a 
single packet as a function of having another such config- 
ured node in their path. The nodes exchange encapsulation 
packets, even though the packets within the encapsulation 
packet may ultimately have different destinations. Compres- 
sion within an encapsulation packet may be performed on 
headers, payloads, or both. 
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GROUP PACKET ENCAPSULATION AND technology before relaying it to the next hop gateway. Such 

COMPRESSION SYSTEM AND METHOD processing consumes computing power and memory and 

causes transmission delay. If data traffic is heavy in a 
CROSS REFERENCE TO RELATED gateway, the gateway may not be able to transmit the data as 

APPLICATIONS * 5 f ast as it is received and network congestion and delays 

result due to excess contention for limited gateway resource 
This application claims the benefit of priority from U.S. and bandwidth. 
Provisional Patent Application Ser, No. 60/238,213, filed |p header compression is a prior art technique that can 

Oct. 5, 2000, entitled Group IP Packet Encapsulation and reduce a packet's size and result in more efficient packet 
Compression. 10 transportation. There are some Internet standard methods for 

IP header compression, such as IP/TCP header compression 
FIELD OF THE INVENTION (RFC 1144) and IP/UDP/RTP header compression (RFC 

2508). Header compression relies on many fields in the 
The present invention generally relates to the field of header being const ant or changing seldomly in consecutive 
electronic communications. More specifically, the present pac kets belonging to the same packet stream. Fields that do 
invention relates to communication protocol systems and 15 not change between packets need not be transmitted at all. 
methods used in such electronic communications. j 0 initiate compression of the headers of a packet stream, a 

full header carrying a context identifier (CID), is transmitted 
BACKGROUND OF THE INVENTION 0 ver the link. The compressor and decompressor store most 

^ T , . . . , . r fields of this full header in a context structure and the CID 

The Internet protocol (IP) is the standard protocol for 2Q tQ be ^ the context structure . ^ context 

carrying out data transmission over the Internet. Prior art strucnjre comprises the fields of the header whose values are 
FIG. 1 shows an open system interconnect (OSI) model 100 constant and thus need not be sent over the link at all, or 
that depicts the different layers of processing involved in IP change little between consecutive headers so that it uses 
data communication within a gateway or host computer. The f ewer bits to send tne difference from the previous value 
model 100 includes application 102, presentation 104, ses- 25 compared to sending the absolute value. After context struc- 
sion 106, transport 108, network 110, data link 112, and mre arK i its CID has been synchronized between the corn- 
physical 114 layers. Each layer understands a certain com- pressor and the decompressor, the compressor can then 
munication protocol, which among other things contains a compress packet headers by computing the difference 
specific packet format. Each layer also employs a standard between the headers and the initial values stored in the 
method of encapsulating and de-encapsulating packets 3Q context structure and encoding only the non-zero values of 
received from upper and lower layers. When a layer receives the difference. After receiving the compressed header 
a packet of data from an upper layer, that layer encapsulates together with the CID, the decompressor retrieves the con- 
the packet into a new packet conforming to the packet text structure using the CID and decompresses the com- 
format the layer understands. The layer then passes the new pressed header. Header compression is most effective for 
packet to the next lower layer. When a layer receives a 35 small packets where the overhead header is significant. The 
packet of data from a lower layer, the receiving layer problem with IP header compression is that, the compressed 
retrieves (i.e., deencapsulates) the encapsulated inner packet packet is no longer a standard IP packet and it depends on 
and passes it to the next upper layer. the data-link layer to carry the compression information 

Prior art FIG. 2 shows a group of diagrams 200 that such that the receiving node can decompress the header and 
illustrate encapsulation at various layers of model 100 as an 40 recover the original packet. This requires that the receiving 
example of UDP/IP over Ethernet, i.e., from the transport node.must have a data-link layer direct connection with the 
layer 108 to the network layer 110 and then to the data link sending node. Therefore, IP header compression has been 
layer 112. At the transport layer 108, a UDP packet 220 applied only on a link-by-link basis. In today's public 
includes a UDP header 202 and data 210. At the network Internet, packet may traverse over many intermediate rout- 
layer 110, the IP packet 230 includes the UDP packet 220 45 ers before reaching the receiving node. As shown in FIG. 3, 
and an IP header 204. And, at the data link layer 112, the IP packets originated from Node A 310 traverse over Node B 
packet 230 is encapsulated in an Ethernet header 206 and 320 and Node C 330 before reaching Node D 340. 
trailer 208, as an Ethernet frame 240. The Ethernet frame Therefore, IP header compression cannot be applied just 
' 240 is transmitted to a physical network connection. It can between Node A 310 and Node D 340. 
be seen from FIG. 1 and FIG. 2, for each layer of encap- 50 IP payload compression (IPComp) is another prior art 
sulation the packet size is increased, which means more technique for improving packet transportation efficiency, 
bandwidth is consumed. For example, the Ethernet header IPComp is an Internet standard method (RFC-2393). 
206 and trailer 208 together add 26 bytes. That is, for each IPComp reduces the size of IP payload before passing the IP 
IP packet transmitted, there will be 26 bytes of overhead in packet to the data-link layer, and therefore increases the 
Ethernet framing. 55 overall communication performance between a pair of com- 

FIG. 3 illustrates an example of prior art data communi- municating hosts/gateways ("nodes"). The IPComp protocol 
cation between nodes, e.g., gateway/host A 310 and operates at the network layer 110 in the OSI model 100, 
gateway/host D 340, which includes transit through gateway illustrated in FIG. 1. 

B 320 and gateway C 330. The data-link layer technologies The compression processing of IP packets has two phases: 
employed by each connection may be different. For illus- 60 compressing of outbound IP packets ("compression") and 
trative purposes, assume the direction of data communica- decompressing of inbound IP packets ("decompression"), 
tion is from gateway/host A 310 to gateway/host D 340. For The compression processing must be loss-less, ensuring that 
each frame of data received in a gateway (e.g., gateway 320 the IP packet, after being compressed and decompressed, is 
or 330), the gateway needs to determine (referred to as identical to the original IP packet. Additionally, the corn- 
routing) which gateway in the next hop to send the data, and 65 pression processing must enforce a non-expansion policy, 
may need to retrieve the IP packet from the frame and that is, if the compressed packet is larger than the original 
encapsulate the IP packet in a different data-link framing packet, the original packet will be transmitted. 
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The data link layer typically imposes a maximum trans- 
mission unit (MTU). For example, the Ethernet has a MTU 
of 1500 bytes. The non-expansion policy ensures the packet 
would not exceed the MTU, which would cause packet 
fragmentation and result in increased overhead. Each IP 5 
packet is compressed and decompressed by itself without 
any relation to s other packets ("stateless compression"), as 
IP packets may arrive out of order or not arrive at all. Each 
compressed IP packet encapsulates a single IP payload. 

An original IP packet 400 is shown in prior art FIG. 4A. 10 
IP packet 400 is shown in a compressed form 420 in FIG. 
4B, in accordance with the prior art protocol IPComp. The 
compressed IP packet 420 contains a modified IP header 
422, an IPComp header 424, and compressed. payload data 
426. The payload data 426 may be compressed using any 15 
known loss-less compression algorithm. The modified 
(indicated by the asterisk) IP header 422 shown in FIG. 4B 
contains a new protocol identification, which is used by the 
remote node to identify the packet as an IPComp com- 
pressed packet. The modified IP header 422 also contains 20 
new value of total length and header checksum for the 
compressed IP packet 420. 

As shown in prior art FIG, 4C, an IPComp header 450 
consists of four-octets, 0 through 3 (i.e., 4 bytes), where the 
field 452 stores an IP (v.4) protocol field or an IP (v.6) Next 25 
Header field of the original IP header; the "Flags" fields 454 
is typically reserved and set to zero; the "Compression 
Parameter Index" (CPI) field 456 identifies the compression 
algorithm used. The remote node receiving the compressed 
IP packet will choose the correct decompression algorithm 30 
according to CPI 456. 

To utilize the IPComp protocol, two nodes must first 
establish a compression association (CA) between them. 
The CA includes all required information for the operation 
of IPComp, including the CPI, the mode of operation, the 35 
compression algorithms to be used, and any required param- 
eter for the selected compression algorithm. Generally, 
IPComp operation is known in the art, so not discussed in 
detail herein. 



In accordance with the encapsulation protocol, two com- 
munication nodes (e.g., a Node-X and a Node-Y) establish 
one or more protocol "associations". A node could be a 
gateway, host computer or some other known communica- 
tion device. In this example, Node-X and Node-Y may be 
configured with modules that implement the system, 
method, and protocol of the present invention. Node-X 
establishes a protocol association for-Node-Y. Among other 
things, a protocol association for Node-X includes an 
address map. The address map comprises a list of addresses 
of nodes for which packets transmitted from Node-X can 
pass through to get to Node-Y. An address for a node could 
be an address for an end system or a subnet address 
representing a sub-network, as examples. Similarly, Node-Y 
can establish a protocol association for Node-X. For packets 
being transmitted from Node-X to Node-Y, only one proto- 
col association is required. 

In accordance with the present invention, when Node-X is 
preparing to transmit packets, Node-X determines which of 
those packets has a destination address that matches an 
address in the address map. The packets are grouped accord- 
ing to having a common destination or intermediate node in 
their path. For a given node address (e.g., Node-Y) in the 
address map, Node-X dynamically combines the group of 
packets into one encapsulation packet with one encapsula- 
tion packet header and one encapsulation payload. The 
encapsulation payload contains the original packet headers 
and payloads. Node-X may optionally compress at least a 
portion of the original packet headers and/or payloads in the 
encapsulation payload, according to known compression 
techniques. The encapsulation packet header contains a 
special protocol identifier referred to as an encapsulation 
packet protocol ID. Node-X transmits the encapsulation 
packet to, in this example, Node-Y, When Node-Y receives 
the encapsulation packet, the encapsulation packet protocol 
ID (or other information encoded in the encapsulation 
packet) is used by Node-Y to identify the received packet as 
an encapsulation packet in accordance with the present 
invention. Node-Y retrieves the encapsulation payload, 



One problem with IPComp is that it requires each IP 40 decompresses the payload, if it has been compressed and 

then de-encapsulates the encapsulation payload. Alter 



packet to be compressed individually without any relation to 
other packets. This requirement limits the ability to com- 
press IP data, so a certain amount of inefficiency generally 
has been tolerated, as being unavoidable. 

SUMMARY OF THE INVENTION 

The invention is a system and method for group packet 
encapsulation and (optionally) compression. The system and 
method increase packet transmission performance between 
two gateways or host computers by reducing data-link layer 
framing overhead, reducing packet routing overhead in 
gateways, reducing packet header overhead, and increasing 
loss-less data compression ratio beyond that otherwise 
achievable with standard protocols, such as IPComp. To 
accomplish this, the system and method implement an 
encapsulation protocol of the present invention, which, as 
an-example, can be used with IP packets, as a group IP 
packet encapsulation and (optionally) compression (GIEC) 
system and method. 

In many situations, a communication device (e.g., node) 
may accumulate multiple packets in its internal queue before 
passing them to the data link layer. The packet accumulation 
could be the result of, as examples, a TCP/UDP protocol 
sending multiple packets at the same time, network conges- 
tion blocking packets in queue, multiple TCP/UDP flows 
transmitting simultaneously between two nodes (e.g., 
gateways/hosts) or some combination thereof. 



45 



50 



60 



65 



de-encapsulating, Node-Y recovers the original group of 
packets and forwards them to the appropriate gateways or 
end systems. That is, for those packets for which Node-Y is 
not the ultimate destination, the packets are sent on to their 
destinations from Node-Y. 

The system and method of the present invention, imple- 
menting the encapsulation protocol, improves transmission 
performance in a variety of manners. For example, data link 
framing overhead is reduced, which results in reduced 
bandwidth consumption. That is, instead of incurring n 
framing overheads for n packets, by encapsulating these n 
packets into one packet, there will be only one framing 
overhead. Additionally, packet routing overhead in gateways 
is reduced. Instead of incurring n overheads in routing n 
packets, by encapsulating these n packets into one encap- 
sulation packet, there is one overhead, as if routing only one 
packet. And, because the encapsulation IP packet is a regular 
IP packet that can traverse any intermediate routers in an IP 
network, IP header compression can be applied on IP 
packets contained in the encapsulation payload without 
requiring Node-X and Node-Y to have a direct data-link 
connection. Also, if compression is applied in IP pay loads- 
contained in the encapsulation payload, the set of data that 
comprise these payloads can be compressed together, rather 
than compressing each IP packet payload individually, as is 
done in the prior art systems. As a result, the compression 
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ratio may be increased, because more data are compressed 
together within a single packet, resulting in reduced band- 
width consumption. 

The encapsulation protocol may farther employ an intel- 
ligent adaptive algorithm (IAA) to prevent the encapsulated 5 
and (optionally) compressed packet from-exceeding the 
MTU. Exceeding the MTU causes packet fragmentation and 
re-assembly, which inevitably introduces overhead in pro- 
cessing and bandwidth. The IAA, at a macro level, includes 
at least two steps. First, the compression ratio for packet 10 
header compression and payload compression for packets 
destined for the same remote node is estimated dynamically. 
The compression ratio is defined as the size of buffer before 
compression divided by the size of buffer after compression. 
The compression ratio can be estimated from compression 15 
ratios obtained from the previous packets. The compression 
ratio can also be continuously updated as an average, over 
a chosen window of time. If no compression is applied, the 
compression ratio can be set to 1, referred to as "null" 
compression. Second, a determination is made of the maxi- 20 
mum length of the encapsulation packet before compression 
is applied. The maximum length determines how many 
packets can be encapsulated together without exceeding the 
MTU. The maximum length' is determined based on the 
known MTU for the corresponding link and the estimated 2 s 
compression ratio. 

Preferably, the encapsulation protocol is backward com- 
patible with known protocols, such as IPComp. That is, the 
system and method of the present invention may employ a 
protocol ID that is adapted from a protocol ID otherwise 30 
assigned to a known protocol (e.g., IPComp). In such a case, 
the encapsulation protocol employs special values in the CPI 
for identifying, as an encapsulation protocol, a known 
protocol. As an example, a standard IPComp header contains 
a 16-bit CPI that identifies a compression algorithm. The 35 
known IPComp standard, defined in RFC-2393, allocates 
CPI values 0-63 for well-known compression algorithms 
and allocates values 61440-65535 for private use among 
cooperating parties. As an example, the encapsulation pro- 
tocol may designate a value range, in the unassigned value 40 
range of 61440-65535, to identify the encapsulation proto- 
col. CPI values in this range may be referred to as encap- 
sulation CPI values. Multiple sets of value ranges can be 
assigned, for example; (6144O+D*100H61540+D* 100-1), 
where D-0,1,2. .. is the ID of the range, and each range has 45 
100 values, for example. Different D values may designate 
different encapsulation schemes, while the values in the 
range may designate different payload compression algo- 
rithms. An encapsulation scheme specifies the formal with 
which multiple IP packets are encapsulated into one IP 50 
packet. For example, D-0 may represent a specific encap- 
sulation scheme, and values 61440-61503 may correspond 
to the same well-known payload compression algorithms 
reserved in CPI values 0-63, and values 61504-61539 may 
designate other compression algorithms. Therefore, if a CPI 55 
value is 61440, it can be known that group packet encap- 
sulation in accordance with the present invention and a 
known encapsulation scheme (D«0) has been applied, and 
the payload compression algorithm is the well-known algo- 
rithm identifier 0. 60 

When header compression is applied, the encapsulation 
scheme may insert a header compression (HC) header before 
each packet header contained in the encapsulation packet. 
The HC header may contain one or more bytes that comprise 
information of header compression scheme ID, encoding 65 
scheme ID, size of the following header, and context iden- 
tifier (CID). Header compression schemes specify types of 
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header compression such as Null-header-compression, 
IP-TCP header compression, BP-UDP header compression, 
and IP-UDP-RTP compression, etc. Null-header- 
compression indicates that the following header is not 
compressed, which allows selective header compression in 
one encapsulation packet. Encoding schemes specify encod- 
ing algorithms used for encoding compressed headers. If an 
implementation will support only one encoding scheme for 
each header compression scheme, it is not necessary for the 
HC header to include an encoding scheme ID. A specific 
encapsulation scheme may also indicate whether any header 
compression has been applied or not, and therefore whether 
a HC header has been inserted before each packet header or 
not in the encapsulation packet. 

With the encapsulation protocol of the present invention, 
header and/or payload compression can be optional. Group 
packet encapsulation, even without compression, signifi- 
cantly increases communication performance in most cases, 
especially when each encapsulated packet is short. Group 
packet encapsulation reduces the overheads associated with 
data link layer framing and with packet routing. Therefore, 
unlike the IPComp protocol, as an example, the encapsula- 
tion protocol of the present invention can be applied to 
payload data that is not compressible, such as speech and 
video data in voice and video over IP communications. 
Group packet encapsulation combining with header and/or 
payload compression can further reduce the encapsulation 
packet size and therefore achieve higher performance. 

To allow the same encapsulation protocol to support 
optional payload compression, the encapsulation protocol 
can further designate a special encapsulation CPI value to 
denote group packet encapsulation with null payload com- 
pression. For example, the value 99 in each range (61540+ 
D* 100-1), where D-0,1,2. . . can be used for the null 
payload compression encapsulation CPI. "Null payload 
compression" means that packet payloads contained in the 
encapsulation packet are not compressed. The same encap- 
sulation protocol can also support optional packet header 
compression by using special encapsulation scheme IDs 
(i.e., D values) to designate null header compression. "Null 
header compression" means that packet headers contained in 
the encapsulation packet are not compressed. 

As previously noted, the system and method of the present 
invention need not use or be backward compatible with the 
IPComp protocol. Depending on the application of the 
system, compatibility with other protocols may be favored 
and implemented in addition to or instead of IPComp, as will 
be appreciated by those skilled in the art. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing and other objects of this invention, the 
various features thereof, as well as the invention itself, may 
be more fully understood from the following description, 
when read together with the accompanying drawings, 
described: 

FIG. 1 is a prior art figure of an OSl model; 
FIG. 2 is a group of diagrams of prior art message formats 
for U DP/IP over Ethernet in accordance with the OSI model 
of FIG. 1; 

FIG. 3 is a prior art network block diagram depicting the 
flow of OSI model packets between nodes; 

FIG. 4A is a diagram depicting a prior art IP packet and 
FIG. 4B is a prior art diagram depicting the IP packet of FIG. 
4A in compressed form in accordance to IPComp; 

FIG. 4C is a prior art diagram depicting an IPComp 
header used in the compressed IP packet of FIG. 4B; 
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FIG. 5 A is a block diagram of GIEC modules in accor- implement the method depicted in flowchart 550 of FIG. 5B. 

dance with one embodiment of the present invention and The GIEC modules 530 are hosted on a node 500 that 

FIG. 5B is a method implemented by the GIEC modules of includes known communication software 510 configured for 

FIG. 5 A* conducting-the transmission and reception of messages over 

FIG. 6 is a block diagram depicting GIEC protocol S a network, having a network interface genera 

associations made at nodes that implement the modules of d ° u ^ arrow 512. Database (DB) 520 may hold packets and 

1 rotator! i t-i r <~\ rrr\ nti An inH VP r»i it i K I A h PC acCA/*TatPfl With 



FIG. 5A and the method of FIG. 5B; 



related information and executable files associated with 
modules 530. 

FIGS. 7A (prior art) 7B (prior art), 7C (prior art), 7D , 7E, ^ rcfcrcncc tQ 55Q of ^ 5B ^ ^ 

and 7F are diagrams depicting vanous GIEC encapsulation ^ & GI£C nod e Node x ^ of piG fe 
schemes implemented by the modules of FIG. 5A and the ^ ^ for transmission b are analyzed by packct ana f yzcr & 
method of FIG. 5B; and groupef S32 of nG §A ^ ft ^ Qf ^ ^ 

FIGS. 8A and 8B are diagrams depicting HC header classified according to a determination that the packets in the 
formats used for packet header compression for GIEC set have a G IEC destination node, e.g., Node-Y 

packets in accordance with the present invention. ^ 604 in lheif path ^ set of packets go i n g l0 G IEC 

For the most part, and as will be apparent when referring destination node are grouped together and within the group 

to the figures, when an item is used unchanged in more than the packets are sequenced, in step 554. Sequencing may be 

one figure, it is identified by the same alphanumeric refer- accomplished by any of a variety of manners, such as, for 

ence indicator in the various figures in which it is presented. example, a first-in-first -out sequence. Note that it is not 

DETAILED DESCRIPTION OF THE *o imperative that .all of the packets ,in a group (or sequence)be 

PREFERRED EMBODIMENT addr ^ for ! he same ^T te destm ^ n < e *' 

ing GIEC node or some other non-GIEC node), but rather 

The invention is a system and method for group packet that a common GIEC node is in the path of the packets in the 

encapsulation and (optionally) compression. The system and group, as a GIEC receiving node, regardless of the ultimate 

method increase packet transmission performance between 25 destination of those packets. 

two nodes (e.g., gateways or host computers) by reducing In step 55^ the packets are combined into an encapsula- 

data-link layer framing overhead, reducing packet routing tion GIEC packct by enca psulation module 534. There are 

overhead, allowing packet header compression without many possible manners for encapsulating the packets, 

direct data link connection and increasing loss-less payload referred to as encapsulation schemes, some of which are 

compression ratio beyond that otherwise achievable with 3Q described in more detail with respect to FIGS. 7 A, 7B, 7C, 

prior art protocols. In the preferred embodiment, the packets 7D> 7E> and 7 p In step 55^ optionally, the packet headers, 

are IP packets and the system and method are a group IP pay loads, or both are selectively compressed by compres- 

encapsulation and (optionally) compression (GIEC) system s j on mo dule 536. Whether compressed or not, a GIEC 

and method implementing a GIEC encapsulation protocol header (e.g., an IP header with protocol ID identifying 

that is optionally compatible with IPComp protocol. Note 35 qj£Q is added to the encapsulation GIEC packet, in step 

that in the present invention, other encapsulation protocols 56 q At pomt a f ter determination of the set of packets, 

may also be supported. However, preferably, the GIEC an intelligent adaptive algorithm (IAA) module 538 may be 

system and method employ the IPComp protocol, as one uscd to cnsurc that the size of the GIEC packet is not greater 

possible payload compression method for IP packets. t han the MTU of the communications path. The GIEC 

In many situations, an IP communication device can 40 packet is transmitted via communication module 510 of 

accumulate multiple IP packets in its internal queue before ' FIG. 5A to a destination GIEC node (e.g. Node-Y 604), in 

passing them to the data link layer of the OSI model 100 of s t e p 562. The GIEC packet is received by the destination 

FIG. 1. The packet accumulation could be the result of, as GIEC node, in step 564, and de-compressed if necessary, in 

examples, the TCP/UDP protocol sending multiple packets step 566. In step 568, the GIEC packet is deencapsulated. 

at the same time, network congestion blocking packets in 45 The original group of packets is reconstructed and the 

queue, multiple TCP/UDP flows transmitting simulta- packets are ungrouped, in step 570. If the GIEC destination 

neously between two routers, gateways, hosts, or some node is not the ultimate destination for a packet, the packet 

combination thereof. is then forwarded along a path to its ultimate destination, in 

In the preferred embodiment, the GIEC system includes step 572. 

GIEC functionality that may be implemented in software, 50 FIG. 6 provides an exemplary block diagram 600 of 

firmware, hardware, or some combination thereof. GIEC several nodes configured to communicate across a network, 

functionality is preferably implemented on a plurality of Among the nodes, a Nbde-L 612 and a Node-M 614 are 

networked communication devices or nodes. A node may be coupled to GIEC Node-X 602. Also, a Node-I 616 and a 

any device capable of generating, transmitting, and/or Node-J 618 are coupled to GIEC Node-Y 604, wherein 

receiving electronic messages, such as a personal computer 55 Node-X 602 and Node-Y 604 are coupled together. In the 

(PC), personal digital assistant (PDA), cell phone, e-mail preferred embodiment, each of (he GIEC Nodes-X and Y 

device, pager, Web or network enabled television or includes the GIEC modules 530 of FIG. 5A. Additionally, 

appliance, server, gateway, host, router or other such Node-X 602 includes an address map 622, which may be 

devices. The devices may be networked together over one or stored in DB 520. Address map 622 comprises a list of 

more of a plurality of types of networks, such as the Internet, eo addresses corresponding to devices or nodes to which 

world wide web (Web), intranet, extranet, private network, Node-X can exchange message traffic. Similar to Node-X 

virtual private net work, local are a network (LAN), wide area 602, Node-Y 604 also includes an address map 624 that 

network (WAN), telephone network, cable network, or some comprises a list of addresses corresponding to devices or 

combination thereof. nodes to which Node-Y can exchange message traffic. An 

Preferably, the GIEC functionality is implemented as a 65 address map is used to facilitate and enable communications 

group of GIEC modules 530, shown in FIG. 5 A, that may be among nodes listed in the map. For example, as shown in 

hosted on any of the aforementioned types of nodes to FIG. 6, address map 622 for Node-X, among other possible 
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addresses, includes an Address-X for Node-X 602, an If compression is to be applied, compression module 536 

Address-L for Node-L 612, and an Address-M for Node-M of FIG. 5A compresses the encapsulation (or the plain) IP 

614. An address map for Node-Y 604 includes, among other packet according to a known header compression scheme 

possible addresses, an Address-Y for Node-Y 604, an • and/or payload compression algorithm. If payload compres- 

Address-I for Node-1 616, and an Address-J for Node-J 608. 5 sion has been performed with a compression algorithm 

Each GIEC node also includes, for each other GIEC node identifier, denoted as "C-ID", the CPI value of the IPComp 

with which it is configured to communicate, a GIEC protocol header (see FIG. 4C) is set to (61 440+D*100+C- 

(protocol) association file. The GIEC association file ID) if it's an encapsulation GIEC IP packet or it is set to CID 

includes information that facilitates and enables communi- if it's a plain IP packet. If no payload compression is applied, 

cation between GIEC nodes and, ultimately, to the non- 1Q the CPI value is set to the GIEC null compression CPI value 

GIEC nodes to which the GIEC nodes are coupled. (61 540+D* 100-1). If header compression is applied, the 

Accordingly, in FIG. 6, Node-X 602 includes a GIEC encapsulation scheme inserts a HC (header compression) 

association file 626 that includes the address map 624 of header before each compressed or uncompressed packet 

Node-Y. Similarly, Node-Y 604 includes a GIEC association header. The HC header comprises a header compression 

file 628 that includes the address map 622 of Node-X 602. scheme ID, size of the following header, and CID identify- 

If more than one encapsulation scheme is supported between mg me structure used in compression. The header 

Node-X 602 and Node-Y 604, a GIEC protocol association compreS sion scheme ID indicates what type of header and 

may include the encapsulation scheme IDs. If packet header ^ faeader faas beefl d 0f not If the header 

compression is to be applied between two GIEC nodes, a compressed, the HC header may not comprise the 

GIEC protocol association may also include header com- Mor / det ail descrip tion about HC header will be 

pression scheme IDs and their associated header context 20 . r.™ OA jod 

structures and context identifiers (CID). If packet payload discussed according to FIGS. 8 A and 8B. 

compression is to be applied between two GIEC nodes, a Payload compression can also be done selectively on 

GIEC protocol association may also include compression portions of the IP packet sequence to be encapsulated. For 

algorithm IDs, which in the preferred embodiment are example, if encoded speech packets and keyboard message 

encoded into a GIEC CPI value, such as a CPI value 456 of 25 packets are encapsulated together, the keyboard message 

a standard IPComp header, for example, as is shown in FIG. packets can be compressed while encoded speech packets 

4C. may not be compressible. The selective payload compres- 

A GIEC protocol association can be established in any of sion can be done before encapsulation or after encapsulation, 

a variety of manners. For example, a GIEC protocol asso- and it may require special encapsulation scheme to accom- 

ciation can be manually entered (e.g., by keyboard) with an 30 modate the information. 

address map of a remote communication node into an Assume that Node-X 602 has transmitted a GIEC IP 

electronic device (e.g., Node-X 602), along with any other packet to Node-Y 604, which is received by communication 

relevant optional parameters. As another example, a GIEC transmit and receive module 510 via interface 512 at 

protocol association can be established automatically, by Node-Y 604 and passed to the packet analyzer and grouper 

employing broadcasting or multicasting protocols, or client- 3s 532 for further GIEC processing. If the IP header contains a 

server based database look up methods. A GIEC protocol GIEC protocol identifier, it is a GIEC protocol processed IP 

association can also be updated dynamically between the packet. In the preferred form, the GIEC protocol employs 

two communication nodes. For example, when packet the IPComp protocol and the GIEC protocol identifier uses 

header compression is applied, new context structures cor- the same IPComp protocol identifier that has been assigned 

responding to new packet streams may be created dynami- 40 the value of 108 by the Internet Standard Organization 

cally and synchronized between the two communication (ISO). The CPI value is retrieved from the IPComp header, 

nodes and saved in a GIEC protocol association. While the If the CPI value is not a GIEC CPI value that is, not in the 

GIEC protocol is not known in the art, such protocol range of (61 440+D*100)-(61 540+D* 100-1), D-0,1. the 

association methods are generally known in the art, so are packet is a regular IPComp packet, and no packet encapsu- 

nol discussed in detail herein. 45 Iation or header compression has been applied and the 

To illustrate data communications between GIEC nodes, payload compression algorithm ID (C-ID) is the CPI value, 

packet transmission from Node-X 602 to Node-Y 604 is If the CPI value is a GIEC CPI value in the range of 

described herein. It is assumed that a GIEC protocol asso- (61 44O+D*100)-(61 540+D* 100-1), D-0,1. . . , the encap- 

ciation 626 for Node-Y 604 has been established on Node-X sulation scheme ID value D and the payload compression 

602. In this example, the GIEC protocol association 626 also 50 algorithm identifier C-ID can be retrieved easily. The encap- 

includes encapsulation scheme IDs, header compression sulation scheme ID specifies the packet encapsulation for- 

scheme IDs and their associated context structures and mat and whether or not header compression has been applied 

CIDs, and payload compression algorithm IDs. In any event, to any inner packet header. 

for each pair of GIEC nodes, the supported header com- At Node-Y, if payload compression has been applied, i.e., 

pression schemes and payload compression algorithms must 55 the C-ID value is not a null payload compression ID, the 

be agreed upon in order for the compression and decora- compressed payload is decompressed by compression mod- 

pression to be successfully implemented by the nodes. That ule 536 using the corresponding decompression algorithm 

is, for. example, Node-X 602 must use a compression designated by the C-ID. If the C_JD is a null payload 
algorithm that is accommodated by Node-Y, so that Node-Y compression ID, payload decompression is not necessary. If 

can decompress the. packets sent by Nodc-X. As mentioned 60 the CPI is a GIEC CPI value and the encapsulation scheme 

above, preferably, the GIEC protocol employs the IPComp ID value (D) indicates header compression has been applied, 

protocol as the base protocol for payload compression and each of the compressed headers in the encapsulation packet 

packet formatting. Accordingly, GIEC CPI values are cho- will be decompressed by compression module 536. After 
sen to be in the range of (61440+D*100)-(61540+D*100- decompression, encapsulation module 534 de-encapsulates 
1), where D-0,1. . . designating an encapsulation scheme, 65 the decompressed GIEC IP packet, and recovers the original 

and the value (61 540+D* 100-1) designating the GIEC null IP packet sequence. It should be emphasized here that other 

payload compression CPI, as described below. protocol designs employing known protocol compression . 
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can be used by the GIEC protocol, and the identification of Header 750 comprises the address of Node-X 602 as source 

a GIEC packet may be based on other information embed- address and the address of Node-Y 604 as destination 

ded in a GIEC IP packet. address. The GIEC IP packet 782 comprises the IP packet 

sequence 720 in the payload with packet headers 731, 733, 

PACKET ENCAPSULATION SCHEMES 5 an H d 735 and paylo [ d * 732) 734 * aad 736 x?mVBA m 

Apacket encapsulation scheme defines the format for the different parts of the payload. A one-byte "No. of packets" 

encapsulation of packets into a GIEC packet. There could be field 754 equaling to the number of packets in the packet 

many different encapsulation schemes for the encapsulation sequence 720 is inserted after the IPComp header 752 to 

of packets. For the most part, a primary requirement for an help Node-Y 604 easily de-encapsulate the GIEC IP packet, 

encapsulation algorithm in accordance with the present 30 A header compression (HC) header (756, 758, and 760) is 

invention is that the GIEC IP packet can be uniquely inserted before each compressed header (731, 733, and 735). 

deencapsulated to recover the original IP packet sequence. Encapsulated payloads 732, 734, and 736 can be compressed 

Some examples of known encapsulation schemes are shown independently. 

in FIGS. 7A 7B and 7C, and encapsulation schemes in The HC headers (756, 758; and 760) comprise informa- 

accordance with the present invention are shown in FIGS. 15 lion that allows Node-Y 604 to decompress each compressed 

7D, 7E and 7R FIG. 7A shows different components of an header and recover the original header (731, 733, and 735). 

IP packet 700. An IP packet 700 comprises an IP header 712 FIG. 8A shows an exemplary composition of a HC header 

and an IP payload 713. The IP payload 713 comprises upper 800, such as the HC headers of FIG. 7E. HC header 800 

layer protocol header (U header) 714 and payload 715. The comprises an "header compression scheme ID" field 802, 

U header 714, for example, could be a TCP header, UDP 2 o "header size" field 804, "CID (context ID)" field 806, and 

header, or UDP/RTP header. The IP header 712 and the U "encoding scheme" field 808. The "header compression 

header 714 together are referred to as header 716. Assume scheme ID" 802 specifies the compression scheme used in 

there are a plurality of IP packets in queue at Node-X 602, header compression. For example, header compression 

designated as IP-1, IP-2, . . . IP-n. Also, within this plurality schemes may implement IP_NULL for no header 

of IP packets, let there be a set, sequence or subsequence of 25 compression, IP_TCP for IP/TCP header compression, 

outgoing IP packets in queue at Node-X 602, designated as IP_UDP for IP/UDP header compression, and IP„UDP_ 

IP-1, IP-2, . . . IP-k where k<-n. Each packet in the set, RTP for IP/UDP/RTP header compression. The header size 

sequence, or subsequence has a destination IP address that field 804 specifies the compressed or uncompressed header 

corresponds to an address in address map 624 contained in size and the CID field 806 specifies the identifier of the 

the GIEC protocol association 626 for Node-Y 604. Once 30 context structure on which the header compression is based, 

determined, the set, sequence, or subsequence of packets, If the header compression scheme is IP_NULL (i.e., no 

e.g., IP-1, IP-2, . . . , IP-k, is designated for encapsulation compression), the CID field 806 can be empty or does not 

into one GIEC packet. exist. 

The grouped set, sequence, or subsequence of packets The encoding scheme field 808 specifies the encoding 

(i.e., IP-1, IP-2, . . . , IP-k), as the case may be, is .35 method used in representing the following compressed 

encapsulated by the encapsulation module 534 of FIG. 5A header. Typically, there is one encoding scheme for each 

into one GIEC packet to be transmitted to the destination header compression scheme, and therefore the encoding 

GIEC node. FIGS. 7B, 7C, 7D, 7E, and 7F demonstrate scheme field 808 is not required, as shown in FIG. 8 B. When 

various encapsulation schemes of encapsulating a packet Node-X 602 is to compress a packet header, it searches a 

sequence 720 into a single GIEC IP packet. FIG. 7B shows 40 context structure matching the packet header, compresses 

the packet sequence 720, including IP packets: IP packet-IP the packet header using the context structure, and encodes 

packet-2. . . IP packet-k. FIG. 7C shows the same the CID associated with the context structure in the HC 

sequence. 720 where each packet is shown to include two header inserted before the compressed header. When 

components, i.e., a header 731 and a payload 732, for Node-Y 604 is to decompress a compressed packet header, 

example. FIGS. 7D, 7E, and 7F show three encapsulation 45 it retrieves the context structure using the CID encoded in 

schemes for encapsulating the packet sequence 720 into a Ihe HC header inserted before the compressed packet 

GIEC IP packet, in accordance with the present invention. header, and decompresses the packet header using the con- 

FIG. 7D illustrates an encapsulation scheme A as one text structure, 

form of GIEC IP packet780, wherein the IP packet sequence FIG. 7F illustrates encapsulation scheme C as one form of 

720 of FIG. 7B has been encapsulated. Encapsulation 50 a GIEC IP packet 784, wherein the IP packet sequence 720 

scheme A supports payload compression. The GIEC IP of FIG. 7B has been encapsulated. With encapsulation 

packet 780 is sent from Node-X 602 to Node-Y 604. The scheme C, the GIEC IP header** 762 is derived from the IP 

GIEC IP Header 741 is an IP header with total length, header of IP packet-1 722 (see FIG. 7B) to eliminate one 

checksum, etc. derived from the IP encapsulation payload extra IP header added in the encapsulation. The original 

790. GIEC IP Header 741 includes the address of Node-X 55 source address 770 and destination address 768 of the IP 

602 as a source address, and the address of Node-Y 604 as packet-1 722 header may be replaced with the address of 

destination address. The GIEC IP packet 780 comprises the Node-X 602 and address of Node-Y 604, respectively. The 

IP packet sequence 720 in the payload that can be further original source address 770 and destination address 768 of 

compressed with compression algorithm ID encoded in the the IP packet-1 722 header may also be saved in the 
IPComp header 742. FIG.7E illustrates an encapsulation 60 encapsulation payload 794 such that the IP packet-1 722 

scheme B as form of a GIEC IP packet 782, wherein the IP header can be reconstructed by NodeY 604. The GIEC IP 

packet sequence 720 of FIG. 7B has been encapsulated. header 762 also replaces other fields such as checksum, total 

Encapsulation scheme B supports both payload compression length, and protocol ID in the IP packet-1 722 header. The 

and header compression. The GIEC IP packet 782 is sent protocol ID in the IP packet-1 722 header is saved in the 
from Node-X 602 to Node-Y 604. The GIEC IP Header 750 65 "Next header" 452 in the IPComp header 450 as shown in 

is an IP header with total length, checksum, etc. derived FIG. 4C. The total length of the IP packet-1 722 header is 

from the GIEC IP encapsulation payload 792, GIEC IP saved in 766 as part of the encapsulation payload. The 
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encapsulation payload can be further compressed. Encapsu- RP: compression ratio for payload compression that is 

lation scheme C does not show header compression. equal to PYS(k)/PYSC(k) 

However, encapsulation scheme C can be revised to include RHE: estimated value for the RH 

header compression in accordance with the present RPE: estimated value for the RP 

invention, as would be appreciated by those skilled m the art. s . . e , . . . , , 

™ 7 GPS(k): size of the GIEC packet 782 after header and 

INTELLIGENT ADAPTIVE ALGORITHM (1AA) payload compression have been performed 

FOR GROUP PACKET SELECTION , GGSE(k): estimated size of the GIEC packet 782 after 

Prior to being transmitted from a first GIEC node to a header and payload compression have been performed 

second GIEC node, when a set, sequence, or subsequence of 30 based on the values of RHE and RPE 

packets is encapsulated into a GIEC packet, it is desirable According to the encapsulation scheme B shown in FIG. 

that the number of packets in the sequence be limited such 7E > lhe GPS(k) value, size of the GIEC packet 782 after 

that the resultant GIEC packet does not exceed the MTU; header and payload compression have been performed, can 

exceeding the MTU would cause packet fragmentation. If De obtained as: 

there is no header compression or payload compression is v 

applied, the total length of the GIEC packet can be easily gp^lps+ics+nps-mdscV.fyscm 

determined for a given encapsulation scheme and a given The HDSC(k) and PYSC(k) cannot be known before header 

sequence of packets to be encapsulated and, therefore, the m( \ payload compression have been performed. The esti- 

maximum number of packets in the sequence to be encap- mated values for HDSC(k) and PYSC(k) however can be 

sulated can be easily determined. If header compression, 20 obtained based on the estimated compression ratios of RHE 

payload compression, or both are applied, the total length of anc j rpe and the HDS(k) and PYS(k), respectively, 

the GIEC packet cannot be determined before compression Therefore, the GGSE(k), the estimated size of the GIEC 

has been performed. Therefore, the limit on the number of packet 782 after header and payload compression have been 

packets in the sequence to be encapsulated cannot be easily performed, can be obtained by: 

determined. The total length of the GIEC packet, however, 25 

can be estimated based on compression ratios estimated GGSE(kyLrs+ics+NPS+NPS*k+HDS(kyRim+FYWRPE 

from the compression results for previous sequences of It ^ desira ble that GGSE(k)<=MTU, which determines the 

packets. For sequences of packets that belong to the same maximum number ( k ) of packets i n the sequence IP-1, 1P-2 

packet stream or similar streams where packets contain Ip . k Dcnole the maximum number of packets as "ink," 

similar characteristics and compressibility, compression 30 and the eqTiation becomes: 
ratios from sequence to sequence are ususally consistent and 

the estimated compression ratios would be more accurate. GGSE(mk)<=MTU, and GGSE(mk+i)>MJV 

When the estimated compression ratios are known, the total _-_ r/1 x , , . , c , , , P 

1 *i_ r *i_ /■'ii-n V * i~ *• * a c - The GGSE(k) value can be computed for each k before 

length of the GIEC packet can be estimated for a given v f , A * . . - . A 

fe * 1 * Cr *■ p \- a header compression and payload compression is performed, 

sequence of packets before any compression is performed, 35 , * • j 1 j ■ u 

a r *u r u *l u e 1 1 * ■ «u After header compression and payload compression have 

and therefore, the limit on the number of packets in the r unc^/i \ a nvcml ^i,.^ 

sequence can be estimated. The 1AA module 538 of FIG. 5A £een performed the HDSC(k) and PYSC(k) values are 

A . . j | - . . - i ■* tt. t a a known, and therefore the true compression ratios RH and Kr 

is an optional module performing this functionality. 1 he 1AA , , . „ unc/iA/umcm^ n ^DD dvcyia/ 

a i a o *• * *u n a i ~*u f »u can be obtained as RH=HDS(k)/HDSC(k) and RP«PYS(k)/ 

module 538 estimates the allowed maximum length or the v ~ „ Tir - . nr»n *u V a * a p \u 

, - • f j u a PYSC(k\ The RHE and RPE can then be updated for the 

GIEC packet before any compression is performed, based on 40 v ' . * i * r ™ i„ 

f. 4 . ■ c I a L encapsulation of the next sequence of packets. For example, 

the estimated compression ratios for header compression u a t e \ 

and for payload compression and the MTU of the transmis- me u P dale tormula can xyt ' 

sion path between the two GIEC nodes in question. To K//E-alptaV?«E+(l-alpha;rrttf, where 0<-alpha<«l 
estimate the allowed maximum length of a GIEC packet, 

denote a packet sequence to be encapsulated as IP-1, 45 an< ^ 

IP-2, . . . , IP-k, k>=l. As an example, assume the encap- RPE-bt\&~RPE+{a-betoyjU> t where o<-beta<-i 
sulation scheme B as shown in FIG. 7E is used and assume 

the following notations: The preferred selection process for a sequence of packets 

LPS: size of IP packet header field 750 IP " 1 ' IP ' 2 • • • IP ; k ^ be encapsulated using encapsulation 

t^o • e , u u A*. a^A w 50 scheme B shown in FIG. 7E may be summarized as follows: 

ICS: size of the IPComp header field 752 5U ^ v ^ . „ V^^™ \ i no t^o vmc 

vt^o • c >u kt c u t a ^A hxa 1) a g ivcn k » compute GGSE(k)»LPS+ICS+NPS+ 

NPS: size of the No. of packets field 754 NPS*k + HDS(k)/RHE+PYS(k)/RPE The initial values 

HCS: size of the HC header 756, 758, and 760 for RHE and R ' p£ can be ^ t0 L 

HDS(k): size of all encapsulated headers 731, 733, and %) Jf GGSE(k)<c , MTU> inc i ude packet lP _ k to the 

735 of the packet sequence S5 sequence for encapsulation. If GGSE(k)>MTU, do not 

IP-1, IP-2 . . . IP-k before any header compression Jp , k tQ ^ scquence for encapsulation ^ and 

HDSC(k): size of all encapsulated headers 731, 733, and sM encapsulating the sequence IP-1, IP-2 . . . IP-(k-l), 

735 of the packet sequence and perform hea d er and payload compression. 

' IP ;!x IP " 2 ' ; ' n P ' k aft6r ' b f 6 !f ^ P ^ i0n , 3) Obtain RH-HDS(k)/HDSC(k) and RP»PYS(k)/PYSC 

PYS(k): size of all encapsulated payloads 732, 734, and 60 (k) aftef header and payload oompnseion have been 

736 of the packet sequence performed. Update the RHE and RPE values by: 
IP-l,IP-2, . . . IP-k before any payload compression 

PYSC(k): size of all encapsulated payloads 732, 734, and JW£-aipha*/tf/£+(i -alpha) *RH> where o<-aipha<-i 

736 of the packet sequence nnr _ mnnr , . 

m , m , r ... , 7. . . RPE=beia m RPE+(o-betii)'RP, where 0<«beta<-l. 

IP-l,IP-2, . . . IP-k after payload compression 65 

RH: compression ratio for header compression that is Note that in the above description, for illustration 

equal to HDS(k)/HDSC(k) purpose, it has been assumed that all packet headers in the 
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sequence of packets have the same compression ratio. This which is about 1500 bytes for Ethernet. Therefore, the GIEC 
may not be the case if these packet headers belong to IP packet can be transmitted over one Ethernet frame. The 
different packet streams and have different types or use result is an Ethernet frame of 321 bytes (295 bytes of GIEC 
different context structures for compression. Therefore, packet +26 bytes framing overhead) transmitted over the 
instead of using one compression ratio for header compres- 5 cable every 20 milliseconds, that is 128.4 kbits/second. A 
sion for estimating the size of the GIEC packet after savings of about 62% of bandwidth consumption for 10 
compression, multiple compression ratios for header voice channels is realized. Alternatively, for the same band- 
compression, each for a different packet stream, may be used width of 344 kbits/second, 29 voice channels instead of 10 
and updated independently. Similarly, if the packet payloads channels can be transmitted without sacrificing voice qual- 
in the sequence of packets are to be grouped according to 10 ity. 

packet streams and compressed group -by-group, multiple For broadband DSL and cable modem access, multiple 

compression ratios, each for different group, may be used layers of framing overheads may be involved for each IP 

and updated independently. packet. For DSL, it may involve IP over PPP and PPP over 

When data compression cannot reduce the packet size, ATM encapsulations. For cable modem, it may involve IP 

group packet encapsulation can still improve the transmis- 15 over Ethernet frame and Ethernet frame (without preamble) 

sion performance through reduced routing overhead and over MAC protocol encapsulations. For these networking 

reduced data link layer framing overhead. Therefore, as long technologies, similar bandwidth saving can be achieved, 

as the resultant GIEC IP packet with null compression does For those payload data that is compressible such as in 

not exceed the MTU, it is transmitted. applications like Telnet and thin client terminals, by further 

As previously mentioned, use of the GIEC system and 20 compressing payloads encapsulated in the GIEC IP packet, 
protocol leads to savings in bandwidth. That is, the GIEC bandwidth savings can be further increased, 
protocol improves transmission performance by reducing The invention may be embodied in other specific forms 
the overheads of data link layer framing and IP packet without departing from the spirit or central characteristics 
routing, compressing encapsulated packet headers without thereof. The present embodiments are therefore to be con- 
requiring link-by-link connection, and increasing the pay- 25 sidered in all respects as illustrative and not restrictive, the 
load compression ratio. For instance, the typical data link scope of the invention being indicated by appending claims 
layer framing overhead ranges from about 10 to 30 bytes per rather than by the foregoing description, and all changes that 
IP packet for ATM, PPP, and Ethernet, and the packet header come within the meaning and range of equivalency of the 
overhead ranges from 20 to 40 bytes per IP packet for claims are therefore intended to be embraced therein. 
IP/TCP, IP/UDP, and IP/UDP/RTP. These overheads are 30 What is claimed is: 

greatly reduced with the encapsulation and, preferably the 1. A method of preparing packets queued at a first node for 
compression. The reduction in framing and packet header transmission to a second node, wherein a maximum trans- 
overheads can be significant for real-time interactive mission unit (MTU) of the path between said first node and 
applications, such as Telnet and voice over IP (VoIP), where second node is known, and said method includes: 
each IP packet has 20 to 100 bytes of payload data. Great 35 A. classifying a set of said packets as a function of having 
benefits are achieved even if the data itself is not compress- a common second node in a transmission path of each 
ible (i.e., loss-less), such as with encoded speech data. packet in said set of packets, wherein said second node 

To illustrate such benefits, following are examples of is configured to de-encapsulate said set of packets; 

communications between two gateways where multiple g encapsulating said set of packets into an encapsulation 

VoIP channels may be simultaneously transmitted over an 40 payload; 

Ethernet connection. Assuming each voice channel uses q deriving an encapsulation packet header from said 

UDP/RTP protocol for transmitting speech data, and assum- encapsulation payload, said encapsulation packet 

ing 20 bytes of encoded speech data are transmitted every 20 header including a destination address; 

millisecond, then for each voice channel, we have an IP D. combining said encapsulation packet header with said 

packet of 60 bytes (i.e., 20 bytes of encoded speech data +12 45 encapsulation payload to form an encapsulation packet, 

bytes of RTP header +8 bytes of UDP header +20 bytes of g determining whether said encapsulation packet exceeds 

IP header) every 20 milliseconds. When the IP packet is & ^ MTU and 

transmitted over an Ethernet frame the frame inu-oduces ^ ^ eliminating one or morc 

another 26 bytes of framing ojcrfiead (i.c. ; 8 bytes of £ a new ^ of 

preamble +14 bytes of frame header +4 bytes of frame 50 k ts d atine parts B throueh F 

trailer), resulting in a total of 86 bytes transmitted over the P£ « ™ of claim 1, further comprising, after part B: 

cable every 20 milliseconds, which is 34.4 kbits/second. ' f , 

Assuming there are 10 voice channels transmitted between G - compressing at least a portion of said encapsulation 

these two gateways, the total bandwidth consumption on ^™ said nod t e * configured to 

each direction would be 344 kbits/second. 55 ^ Com P r ^ S * ld t 

Assuming the GIEC protocol is used with encapsulation * ™ c method of claim 1 wherein each packet in said set 

scheme B shown in FIG. 7E, on every 20 milliseconds, 10 of packets comprises a header and a payload, said method 

IPpacketsforthelOvoicechannelscanbeencapsulatedinto further comprising, prior to part E: 

one IP packet. Further assuming that IP/UDP/RTP header G. compressing headers of a plurality of packets in said 

compression is performed, which typically can reduce the 60 set of packets in said encapsulation payload, 

IP/UDP/RTP header to 4 bytes, and assuming each HC wherein said second node is configured to decompress 

header is 3 bytes and the "No. of packets" 754 is 1 byte, then said compressed headers in said encapsulation payload. 

the total length of the GIEC packet is 295 bytes (20 bytes of 4. The method of claim 1, wherein each packet in said set 

GIEC IP header +4 bytes of IPComp header +1 byte of of packets comprises a header and a payload, said method 

number of packets +3*10 of all HC headers +4*10 of all 65 further comprising, prior to part E: 

compressed IP/UDP/RTP headers +20*10 of all voice G. compressing payloads of a plurality of packets in said 

payloads). The GIEC IP packet is still well below the MTU, set of packets in said encapsulation payload, 
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wherein said second node is configured to decompress 
said compressed payloads in said encapsulation pay- 
load. 

5. The method of claim 1, wherein said packets are EP 
packets having a header chosen from a group comprising: 

1) IP header; 

2) IP/TCP header; 

3) IP/UDP header; 

4) IP/UDP/RTP header; 

5) IP/UDP/RTCP header; 

6) IP/FTP header; 

7) IP/TFTP header; 

8) IP/HTTP header; 

9) EP/SMTP header; 

10) IP/POP header; 

11) IP/SNMP header; 

12) IP/TELNET header; 

13) IP/DNS header; 

14) IP/IPSEC header; 

15) IPINFS header; 

16) IPINetBIOS header; and 

17) IPIRPC header. 

6. The method of claim 1, wherein said packets are IP 
packets and said packets include data chosen from a group 
comprising: 

1) static data; 

2) audio data; 

3) video data; 

4) voice over EP data; and 

5) video over P data. 

7. The method of claim 1, wherein said set of packets 
includes at least two packets and each packet in said set of 
packets includes a header and a payload and part B includes: 

1) combining at least two of said headers; and 

2) combining at least two of said payloads. 

8. The method of claim 7, further comprising compressing 
said combined headers. 

9. The method of claim 7, further comprising compressing 
said combined payloads. 

10. The method of claim 1, further including computing 
a size value and a checksum value for said encapsulation 
packet. 

11. The method of claim 1, wherein each packet in said set 
of packets comprises a header and a payload and wherein 
said encapsulation packet header is derived from a first 
packet header. 

12. The method of claim 11, wherein said method further 
includes: 

G. compressing at least a portion of said encapsulation 
packet payload using a compression algorithm, 

wherein said encapsulation packet includes a compression 
identifier, wherein said compression identifier indicates 
the compression algorithm used by said first node to 
compress said portion of encapsulation packet payload. 

13. The method of claim 1, wherein said classifying a set 
of said packets in Part A includes matching a destination 
address contained in a packet, from said set of packets, with 
at least one of a plurality of addresses for devices configured 
to couple to said second node. 

14. The method of claim 2, wherein said first node and 
said second node are coupled together via a network that 
includes at least one of the following: 
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1) Internet; 

2) world wide web; 

3) extranet; 

4) cable network; 

5) private network; 

6) LAN; 

7) WAN; 

8) virtual network; and 

9) telephone network. 

15. The method of claim 1, wherein said classifying a set 
of said packets in Part A includes matching a destination 
address contained in a packet, from said set of packets, with 
at least one of a plurality of addresses for devices configured 
to couple to said second node. 

16. A method of data communication between a first node 
having packets queued thereat and a second node, wherein 
a maximum transmission unit (MTU) of the path between 
said first node and second node is known, and said method 
includes: 

A. classifying a set of said packets as a function of having 
said second node in a transmission path of each packet 
in said set of packets; 

B grouping said set of packets to form a sequence of 
packets; 

C. encapsulating said sequence of packets as an encap- 
sulation payload; 

D. deriving an encapsulation packet header from said 
encapsulation payload, said encapsulation packet 
header including a destination address; 

E. combining said encapsulation packet header and said 
encapsulation payload as an encapsulation packet; 

F. determining whether said encapsulation packet exceeds 
said MTU; 

G. if said MTU is exceeded, eliminating one or more 
packets from said set of packets to form a new set of 
packets and repeating parts B through G; 

H. transmitting said encapsulation packet from said first 
node to said second node; 

I. receiving said encapsulation packet at said second node; 
and 

J. de-encapsulating said encapsulation packet at said 
second node. 

17. A data communication system having a first node 
coupled to a second node, wherein a maximum transmission 
unit (MTU) of the path between said first node and second 
node is known to said first node, said system comprising: 

A. said first node including a storage device having 
packets queued therein, said first node comprising: 

1) a packet analyzer module, configured to group a set 
of said packets as a function of said second node 
being in a transmission path of each packet in said set 
of packets, wherein each packet in said set of packets 
comprises a header and a payload; 

2) an encapsulation module, configured to generate an 
encapsulation packet including an encapsulation 
payload derived from said set of packets and a 
encapsulation packet header; 

3) a compression module, configured to compress said 
headers of a plurality of packets in said set of packets 
in said encapsulation payload, wherein said com- 
pression module is configured to estimate a com- 
pression ratio related to said encapsulation packet; 

4) an intelligent adaptive module, configured to esti- 
mate the size of said encapsulation packet as a 
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function of said compression ratio and a size of each 
packet in said set of packets and to determine 
whether said encapsulation packet exceeds said 
MTU; 

5) a first communication module configured to transmit 
said encapsulation packet to said second node; and 
B. said second node including a storage device, said 
second node comprising: 

1) a second communication module configured to 
receive said encapsulation packet; 

2) a de-encapsulation module, configured to 
de-encapsulate said encapsulation packet, wherein 
said de -encapsulation includes reforming each 
packet in said set of packets from said encapsulation 
packet; and 

3) a decompression module, configured to decompress 
said compressed headers in said encapsulation pay- 
load. 

18. The system of claim 17, wherein said intelligent 
adaptive module is configured to eliminate at least one 
packet in said set of packets if said MTU is exceeded. 

19. A data communication system having a first node 
coupled to a second node, wherein a maximum transmission 
unit (MTU.) of the path between said first node and second 
node is known to said first node, said system comprising: 

A. said first node including a storage device having 
packets queued therein, said first node comprising: 

1) a packet analyzer module, configured to group a set 
of said packets as a function of said second node 
being in a transmission path of each packet in said set 
of packets; 

2) an encapsulation module, configured to generate an 
encapsulation packet including an encapsulation 
payload derived from said set of packets and a 
encapsulation packet header; 

3) a first communication module configured to transmit 
said encapsulation packet to said second node; and 

4) an intelligent adaptive module, configured to esti- 
mate the size of said encapsulation packet as a 
function of a size of each packet in said set of packets 
and determine whether said encapsulation packet 
exceeds said MTU; and 

B. said second node including a storage device, said 
second node comprising: 

1) a second communication module configured to 
receive said encapsulation packet; and 

2) a de-encapsulation module, configured to 
de-encapsulate said encapsulation packet, wherein 
said de-encapsulation includes reforming each 
packet in said set of packets from said encapsulation 
packet. 

20. The system of claim 19, wherein said encapsulation 
module includes: 

i. a payload module, configured to encapsulate said set of 
packets as said encapsulation payload; 

ii. a packet header module, configured to derive said 
encapsulation packet header from said encapsulation 
payload, said encapsulation packet header including a 
destination address; and 

iii. a combiner module, configured to combine said encap- 
sulation payload and said encapsulation packet header. 

21. The system of claim 19, wherein: 
said first node further includes: 

4) a compression module, configured to compress at 
least a portion of said encapsulation payload; and 
said second node further includes: 
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3) a decompression module, configured to decompress 
said compressed portion of said encapsulation pay- 
load. 

22. The system of claim 19, wherein each packet in said 
set of packets comprises a header and a payload, wherein: 

said first node further includes: 

4) a compression module, configured to compress 
headers of a plurality of packets in said set of packets 
in said encapsulation payload; and 

said second node further includes: 

3) a decompression module, configured to decompress 
said compressed headers in said encapsulation pay- 
load. 

23. The system of claim 19, wherein each packet in said 
set of packets comprises a header and a payload, wherein: 

said first node further includes: 

4) a compression module, configured to compress 
payloads of a plurality of packets in said set of 
packets in said encapsulation payload; and 

said second node further includes: 

3) a decompression module, configured to decompress 
said compressed payloads in said encapsulation pay- 
load. 

24. The system of claim 19, wherein, if said MTU is 
exceeded, said intelligent adaptive module is configured to 
eliminate at least one packet in said set of packets. 

25. The system of claim 19, wherein said second com- 
munication module is further configured to route each 
packet in said set of packets to a next destination, wherein 
for each packet in said set of packets said next destination is 
derived from a content of said packet, 

26. The system of claim 19, wherein said first node and 
said second node are coupled together via a network that 
includes at least one of the following: 

1) Internet; 

2) world wide web; 

3) extranet; 

4) cable network; 

5) private network; 

6) LAN; 

7) WAN; 

8) virtual network; and 

9) telephone network. 

27. The system of claim 19, wherein said packets are IP 
packets including data from a group comprising: 

1) static data; 

2) audio data; 

3) video data; and 

4) voice over IP data. 

28. The method of claim 19, wherein said packet analyzer 
module is configured to match a destination address con- 
tained in a packet, from said set of packets, with at least one 
of a plurality of addresses for devices configured to couple 
to said second node. 

29. AGIEC protocol for conducting data communications 
between a first node having a plurality of IP packets queued 
thereat, at least some of said IP packets including an IP 
header and an IP payload, and a second node, wherein a 
maximum transmission unit (MTU) of the path between said 
first node and second node is known, said protocol com- 
prising: 

A. classifying a set of said IP packets as a function of 
having said second node in a transmission path of each 
IP packet in said set of IP packets; 
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8 grouping said set of IP packets to form a sequence of 
IP packets; 

C. encapsulating said sequence of IP packets as an encap- 
sulation payload; 

D. deriving an IP encapsulation packet header from said 
encapsulation payload, said encapsulation packet 
header including a destination address; 

E. combining said EP encapsulation packet header and 
said encapsulation payload as an IP encapsulation 
packet; 

F. determining whether said encapsulation packet exceeds 
said MTU; 

G. if said MTU is exceeded, eliminating one or more IP 
packets from said set of IP packets to form a new set of 35 
IP packets and repeating parts B through G; 

H. transmitting said IP encapsulation packet from said 
first node to said second node; 

I. receiving said IP encapsulation packet at said second 
node; and 

J. de-encapsulating said IP encapsulation packet at said 
second node, thereby reforming each IP packet in said 
set of IP packets. 
30. The GIEC protocol of claim 29, wherein said IP 
headers are chosen from a group comprising: 

1) IP header; 

2) IP/TCP header; 

3) IP/UDP header; 

4) 1P/UDP/RTP header, 

5) IP/UDP/RTCP header; 

6) IP/FTP header; 

7) IP/TFTP header; 

8) IP/HTTP header; 

9) IP/SMTP header; 
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10) IP/POP header; 

11) IP/SNMP header; 

12) IP/TELNET header; 

13) IP/DNS header; 

14) IP/IPSEC header; 

15) IP/NFS header; 

16) IP/NetBIOS header; and 

17) IP/RPC header. 

31. The GEC protocol of claim 29, wherein said first node 
and said second node are coupled together via a network that 
includes at least one of the following: 

1) Internet; 

2) world wide web; 

3) extranet; 

4) cable network; 

5) private network; 

6) LAN; 

7) WAN; 

8) virtual network; and 

9) telephone network. 

32. The GEEC protocol of claim 29, wherein said IP 
packets include data from a group comprising: 

1) static data; 

2) audio data; 

3) video data; and 

4) voice over IP data. 

33. The GIEC protocol of claim 29, wherein said classi- 
fying a set of said packets in Part A includes matching a 
destination address contained in packet, from said set of 
packets, with at least one of a plurality of addresses for 
devices configured to coupled to said second node. 
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